<HTML>
<Head>

<Title>ELKS Bugs</Title>

</Head>
<Body BGColor=White Text=Black Link=Blue VLink=Magenta ALink=Red>

<H1 Align=Center>ELKS BUGS</H1>

<P Align=Justify>This is a list of reported bugs with ELKS, together with
the current status thereof.</P>

<P Align=Justify>As and when you discover new bugs, please report them to
the <A HRef="http://www.sf.net/projects/elks">ELKS Bugzilla System</A> on
the <A HRef="http://elks.sf.net">ELKS website</A>. This file will be
updated from there.</P>

<HR Width=95%>

<H2 Align=Center>CONTENTS</H2>

<OL>

<LI><P Align=Justify>Bugs reported <A HRef="#Early">prior to June 2001</A>
that may not still exist.</P>

<LI><P Align=Justify><A HRef="#Latest">Latest Bugs</A>.</P>

</OL>

<HR Width=95%>

<OL>

<LI><A Name="Early"><P Align=Justify>Bugs reported prior to June 2001
that may or may not still exist.</P>

<P Align=Justify>The ELKS source tree contained details of the following
bugs when the bug reporting system was moved over to HTML format in June
2001:</P>

<OL>

<P Align=Justify>This is a list of things I have noticed go wrong. Please
submit additions to this file if you find any kernel related bugs.</P>

<P Align=Right><A HRef="MailTo:ajr@ecs.soton.ac.uk">Al Riddoch</A></P>

<HR Width=90%>

<LI><H3 Align=Justify>Sometimes unmounting a non-root filesystem returns
EBUSY when nothing is using, and nothing seems to rectify it.</H3>

<P Align=Justify>On 26th March 2001, <A
HRef="MailTo:tgm9999@Yahoo.com">Thomas McWilliam</A> reported that his
bugfix for this bug had finally been committed to the ELKS development
tree.</P>

<LI><H3 Align=Justify>Sometimes for no aparent reason the umount command
gives a STACK collided with BSS error without unmounting the
filesystem.</H3>

<LI><H3 Align=Justify>Deleting data from the filesystem results almost
always with a "Deleting block not in data zone" type error message, and
sometimes crashes.</H3>

<P Align=Justify>This seems to be due to the following line in
V1_trunc_direct</P>

<P><Pre>
	-               p = i + inode->u.minix_i.u.i1_data;
	+               p = inode->i_zone[i];
</Pre></P>

<P Align=Justify>The botton version being the ELKS version, the top one is
the Linux version. The two don't seem to bear any relation to each other.
This has now nearly been fixed by chenging the above line to</P>

<P><Pre>
			p = &inode->i_zone[i];
</Pre></P>

<P Align=Justify>But blocks are still not freed when the fs is checked
later, and neither is the inode! Looking through truncate.c, and
minix_free_block, there is heavy use of longs which are just not
necessary.</P>

<P Align=Justify>Fixed excessive use of longs, and got fs to the stage
where some blocks are freed, and deleting large files no longer results in
a system crash.</P>

<LI><H3 Align=Justify>Adding register variables to schedule causes the chq
wait queue to get corrupted.</H3>

<P Align=Justify>See comments at the top of schedule() in kernel/sched.c.
I occasionly get the same wait_queue corruption message when heavily
testing the multitasking.</P>

<LI><H3 Align=Justify>Shell sometimes reports "No such file or directory"
when it means "Out of memory".</H3>

<LI><H3 Align=Justify>Long command lines cause programs to crash.</H3>

<P Align=Justify>When copying files from the /bin directory of a floppy
onto the harddisk when installing, the cp process often crashes before it
has finished and frequently displays unexpected behavoir. This could be
because there is a problem dealing with command lines of more than a
couple of hundred bytes, or it could be a problem that comes up after
copying lots of data between files. The bug occurs irespective of whether
the commandline was typed in by hand, or automacally constructed using
wildcards.</P>

</OL>

<HR Width=95%>

<LI><H2 Align=Justify>Recent Bugs</H2>

<P Align=Justify>The following bugs have been reported since 1st June
2001:</P>

<OL>

<LI><H3 Align=Justify>24th June 2001: Signals not checked when
needed.</H3>

<P Align=Justify>Currently signals are only checked when returning from
system calls. They should also be checked when returning from a context
switch.</P>

<P Align=Justify>Consider an ELKS program containing this infinite
loop:</P>

<P><Pre>
	for (;;) {
		i++;
	}
</Pre></P>

<P Align=Justify>There is no way that this program can be interrupted.
Hitting Control-C will not work. No system calls are made, so the signal
is never received. The program will run forever.</P>

<P Align=Justify>What *should* happen is that the kernel *also* checks for
signals on return from a context switch, then eventually the signal will
be received.</P>

<P Align=Right><A HRef="MailTo:tgm9999@Yahoo.com">Thomas
McWilliams</A></P>

</OL>

</OL>

<HR Width=95%>

<P Align=Justify>This document was last updated on 13th August 2001.</P>

</Body>
</HTML>
